1. Field of the Invention
The present invention relates to a message processing method in a distributed system in which software is handled as a component, and processing proceeds by exchanging messages between a plurality of components.
2. Description of the Related Art
A distributed object technology allows software components (to be referred to as components) distributed on a plurality of processes or a network to exchange electronic information without paying attention to the physical location of the partner. In this specification, such electronic information will be called a message. In the distributed object technology, components running in different processes on the same computer, or components running on different computers via a network communicate messages to each other. Typical examples of the distributed object system are
(1) RPC (Remote Procedure Call) (see “‘RPC: Remote Procedure Call Protocol Specification Version 2’, Sun Microsystems”)
(2) CORBA (Common Object Request Broker Architecture®) (see “‘Common Object Request Broker Architecture: Core Specification’, Object Management Group, Inc.”)
(3) JavaRMI (Java Remote Method Invocation (Java is a registered trademark) (see “Jim Farley, (Translated by Yuichi Omata), ‘Java Distributed Computing’, O'REILLY Japan”).
These distributed object technologies have born abundant fruit in relatively large-scale systems such as a transaction processing system, data collection system, and Web service. Recently, a growing number of products are equipped with a plurality of CPUs or multiprocessor OSs even in the embedded technology. The occasion to employ communication middleware having functions equivalent to RPC and CORBA is increasing.
The communication middleware hides cumbersome communication between threads or processes, and implementation of network processing. Components exchange messages, data, and events (to be referred to as messages at once) between them using a predetermined API of communication middleware, improving component portability.
One typical implementation for realizing the distributed object technology is a server-client model. In the server-client model, a client component (to be referred to as a client) requests the use of a service, of a server component (to be referred to as a server) which provides the service. In response to the request, the server executes the service, and sends a requested message to the client. In a server-client model-based system, a client and server are not always in one-to-one correspondence. In most configurations, a plurality of clients request processes of one server. Thus, the server has a queue, temporarily registers processing request messages from a plurality of clients in the queue, and upon completion of preceding processing, extracts the next message from the queue and processes it. The server is configured to reply to a request from a client without assuming a client which requests a service. The server can be implemented without taking account of the communication partner, realizing a highly portable server component. To improve component portability, it is important to communicate between partner components without designating one component by the other.
A recent advanced message communication technology is a Publish/Subscribe model (to be referred to as a Pub/Sub model). Similar to the server-client model, the Pub/Sub model also queues messages to achieve many-to-many communication. In the Pub/Sub model, a receiver (to be referred to as a subscriber) declares in advance that it is interested in a message attribute (to be referred to as a topic) it wants to receive (this operation will be called subscription). A transmitter (to be referred to as a publisher) issues a message about a given topic. Communication middleware delivers the issued message to all subscribers that have registered subscriptions. A feature of this scheme is that both the publisher and subscriber need not know information of the partners.
In the Pub/Sub model, both the publisher and subscriber need not recognize even the network configuration of the system. Each system keeps running normally regardless of the state of the partner. In short, the Pub/Sub model is a loosely coupled system, and has higher component portability than the server-client model system in which a client designates a server and sends a message.
When implementing the above-mentioned one-to-many or many-to-many message delivery system in an embedded system, there would be quiet a number of use cases in which a message delivered in the past needs to be received. For example, a case in which a copying machine where a plurality of components runs in cooperation with each other on a multi-CPU is to be activated quickly will be examined. In general, a building component of the copying machine communicates messages to other components, and activates the system while normally updating the state of the building component. However, all components cannot be activated simultaneously owing to resource limitations of the CPU, memory, and the like, so some components are activated sequentially. To start up the system quickly, components necessary to at least operate the system need to be activated preferentially. Even at this time, there is a need to receive, by a component activated later, a message delivered by a component activated first, and normally update the state of the component activated later as if it were activated from the beginning.
As another use case, even when a subscription from a subscriber is not received temporarily owing to a communication path fault or the like in a system which implements the Pub/Sub model, the subscriber wants to receive an expected message. However, an implementation in which a transmission component such as a server or publisher holds a message in consideration of a component that sends reception request and/or subscription later, is not desirable because this degrades the high portability, as described above.
To solve this problem, there is proposed a method of holding a message in communication middleware for a predetermined period not to delete the message immediately after delivery (see Japanese Patent No. 3732671). There is also known a method of, when the message issue time of a message issued by a publisher is later than the subscription time of a subscriber, delivering the message to the subscriber (see Japanese Patent Laid-Open No. 2008-124977).
In the technique disclosed in Japanese Patent No. 3732671, a message issued by a transmission component is held for a predetermined period, and can be transmitted to a reception component activated with a delay. A case in which a reception component is activated later in order to realize the foregoing activation time shortening use case will be examined. At this time, the message holding period may elapse depending on the activation timing of the reception component, and the reception component may not be able to receive an expected message. When the message holding period is set long in consideration of this, the data holding area becomes full soon if the message issue interval of a transmission component is short. Generally, the timing when a reception component is activated and starts receiving a message depends on the activation mode and the use state of the product. In many cases, a reception component is dynamically generated in accordance with the use state of the system. It is therefore difficult to accurately predict the message holding period. To reliably receive a message expected by a component activated later, it is not sufficient to determine the message deletion timing only by the message-holding period.
In the technique disclosed in Japanese Patent Laid-Open No. 2008-124977, a subscriber registers a subscription together with the subscription time. Even if the subscription is not received temporarily owing to a network fault or the like, the subscriber can receive a message issued by a publisher after the subscription time. However, in device-embedded software, the number of running components is often limited as typified by the copying machine quick activation use case. In most cases, it is difficult to operate a subscriber and register a subscription before the publisher runs.